+ZcTo: )H Tim, Karim, Mark, Dick, Brad ( Å ZFrom: )H Peter Young ( ü ZDate: )H
July 13, 1990 ( Ω ZSubject: )H DSP Emulator ( à Z<------------------------------------------------------------ ( Ã˛- ( € Z/----------------------------------------------- +<DSP Emulator is not a great name for the software with which ( ZAthat name has become associated. Perhaps a good first step is to *:delineate what we think of as comprising the DSP Emulator. +?1) This top level of software is what I have always refered to (> Z>as the "Model" and which roughly corresponds to the structures *>described in "Proposed Sequencer Data Structures for NU-ARCH". *=The Model implements maintenance and editing of a sequence in *Babstract with as little knowledge of the user or machine interface *Bas possible. There are definite differences between the to Models *#today, and they are outlined below. +=2) The Machine. Just as we worked very hard to separate the (≥ ZBuser interface from the model, we tried to keep the machine (DtoD, *EVTR) interface separate from the model. This is a large body of code *@that manages the various hardware devices that may be interfaced *Dto SoundDroid (or any application which to utilize the DtoD or VTR). +<3) The DtoD and VTR interfaces. This bottom level of code (
ZCprovides the direct interface to the hardware. By necessity, it is *emeshed in the Machine. +There is really a fourth level of code and that is the (C ZBimplementation of the protocol on the DtoD or DSP. This code must *Abe enhanced in order to provide necessary features to the above 3 * levels and the user interface. +:The main reason I continue to call this collection the DSP (ã Z=Emulator is to remind myself that as much of this software as *?possible will port to the DSP. Specifically, that applications *Edeveloped to run on the model will have to change very little to move *from the DtoD to the DSP. ˇ ( Ÿ( ˇ ˇˇˇˇ ( Ÿ
d
+Z` How these areas will change. *Model +=There are significant differences between LFL's model and the ( • Z=model described in "Proposed Sequencer Data Structures for NU ( •Â- ( ¥ ZDARCH". The LFL model is a cue, event, track, sequence architecture *>which will have change to a trigger, cue/fader/MIDI, threaded *sequence architecture. +:Above that LFL will subclass the model to create the track ( ¸ Z?based sequence that SoundDroid depends on and LFL will subclass *Ethese cues (if NED decides not to) to provide the 4 cue types used by *-spotter (Foley, Dialog, Production, Effects). +<The existing model implemented by LFL may or may not provide (D Z?much help to NED in implementing their NU-ARCH. It is also not *Cclear if the true NU-ARCH model can be implemented on a DtoD, but I *Fhope so. The biggest barrier appears to be track organization of cues *@on the DtoD. Hopefully, the thread mechanism and some temporary **fields in the model can solve the problem. *Machine +=I have almost no idea how the machine will have to change to (≈ ZAaccommodate NED needs and NU-ARCH compatibility. I am interested *?in your response to the machine now that you have had some more *time to look at it. *DtoD and VTR interfaces +:Hopefully, NED will be able to soup up the reliability and (( ZCperformance of the existing DtoD interface as well as extend it for *=SoundDroid Lite. Beyond that I have almost no idea how the *@hardware interfaces will have to change to accommodate NED needs *=and NU-ARCH compatibility. Once again I am interested in you *9response once you have had a chance to study the machine. ˇ ¯
